perm filename HSTHST.OLD[DLN,MRC] blob
sn#308608 filedate 1977-10-03 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00013 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 00002 *** DRAFT *** *** DO NOT BELIEVE *** *** DO NOT DUPLICATE *** *** DRAFT ***
C00004 00003 PREFACE
C00007 00004 INTRODUCTION
C00011 00005 CONNECTIONS
C00015 00006 THE NETWORK CONTROL PROGRAM
C00019 00007 PACKET FORMAT
C00022 00008 NOTES ON PACKET FORMAT
C00024 00009 OP CODES
C00027 00010 SEQUENTIAL LIST OF NETWORK CODES
C00031 00011 ESTABLISHING AND TERMINATING A CONNECTION
C00036 00012 GLOSSARY
C00039 00013
C00043 ENDMK
C⊗;
*** DRAFT *** *** DO NOT BELIEVE *** *** DO NOT DUPLICATE *** *** DRAFT ***
DIALnet memo #2
DIALnet Protocols
(or, the Protocols of DIAL)
Host-Host Protocols
9/28/77
These protocols are being developed as part of the
DIALnet project at the Stanford University Artificial
Intelligence Laboratory supported by NSF grant MCS 77-02080
with John McCarthy as Principal Investigator. The project
is described in a paper available online at ARPAnet host
SU-AI (octal 13, decimal 11) as DIALNE.MEM[DLN,MRC]
*** DRAFT *** *** DO NOT BELIEVE *** *** DO NOT DUPLICATE *** *** DRAFT ***
PREFACE
This document specifies a protocol for use in communication between
Host computers on the DIALnet network. In particular, it provides for
connection of independent processes in different hosts, control of
the flow of data of established connections, and other related
functions.
Although self-contained, this document specifies only one of the
DIALnet protocols. In particular, while this protocol specifies
how data is to be transmitted in between processes on DIALnet, it
does not define in what format the data is to be sent, nor does it
define how the processes are expected to use the data received.
This Host-Host protocol is the "second level", or secondary protocol
used on DIALnet. The Host-Network protocol, or primary protocol, is
currently the same as the RS232C communication protocol. The Process-
Process protocols, or tertiary protocols, are described elsewhere.
Questions concerning DIALnet protocols should be addressed to:
Mark Crispin
Stanford Artificial Intelligence Laboratory
Stanford, California 94305
(415) 491-1407
MRC @ SU-AI
Copies of all DIALnet-related correspondence should be sent to John
McCarthy, DIALnet principal investigator, and Les Earnest at the above
US mail address or to JMC@SU-AI and LES@SU-AI.
It is the intent of the author that these protocols are both simple
in their implementation and powerful in their operation. Certainly
a major design consideration was to design protocols that ordinary
mortals could implement on their systems.
The intended audience of DIALnet ranges from fairly small to quite
large systems, however, DIALnet has been designed to be nice for
medium sized time-sharing systems, such as PDP-10's and DECsystem-20's.
INTRODUCTION
DIALnet provides a capability for geographically separated computers,
called Hosts, to communicate with each other. The Host computers
typically differ from one another in type, speed, word length,
operating system, etc. Each computer utilizes the network via the
ordinary phone lines and special modems using the primary protocol.
This protocol, however, is insufficient to specify meaningful
communication between processes running in two dissimilar hosts.
The processes must have some agreement as to the method of initiating
communication, the interpretation of transmitted data, etc. While it
is possible for individual pairs of hosts or processes interested in
communication with each other to establish private protocols, it is
more desirable for a network-wide set of standard protocols to be
established to minimize the amount of implementation effort involved
in network-wide communication.
Hence, a "layered" approach to communications protocols similar to
those of the ARPAnet are specified here. The primary layer is the
RS232C protocol of the dial-up modems. The secondary protocol,
described here, is the host-host protocol, which is used by all
higher-level protocols. The tertiary protocols, described elsewhere,
include:
TLNT Mapping of an arbitrary console keyboard/printer at
the local host to a network virtual terminal which
communicates with a terminal server process at the
remote host. The remote host's server process maps
the virtual terminal's protocol into the host's own
local terminal's protocol. In this manner, users of
one host can connect to another and log in, etc. as
if they were at a local console at the remote host.
MAIL Sending and receiving letters between different users
at different hosts.
LINK Process-to-process immediate character at a time
communication.
MSG Process-to-process immediate line at a time
communication.
FTP File transfer protocol for reading, writing, and
manipulating files at a remote host.
CONNECTIONS
A connection is established between two entities over a LINK which
is one of 256 logical data paths between each host. A link can be
thought of as a patch cord connecting the two processes at their
respective hosts.
At each end of the link there is a socket; which can be compared to
sockets where a patch cord plugs into. A socket can only be connected
to one link at a time, and each link has a pair of sockets, one at
each host. The pipelines are bi-directional, so in the typical case,
a duplex connection between two processes, only one link is needed.
Basically this is what is usually wanted, so things have been designed
to make this sort of connection super simple.
A link may use entirely different socket numbers at each host; the
socket numbers are assigned by each host's NCP from what sockets are
available and free at the moment.
A link is also "connected" to socket 0 at each host; this "connection"
is unlike the process-to-process connection in that it is reserved for
process-to-NCP or NCP-to-NCP messages. Only NCP messages may be sent
to socket 0; and, conversely, NCP messages may only be sent to socket
0.
Links are the only facility provided by the network. However, there
is a difficulty in getting processes to get a connection between them,
since a process doesn't know the other process' socket number, or even
if the other process currently exists! Also, the other host may not
want the other process to exist until somebody wants to connect to it.
This problem is solved by process ID's, which are ASCII identifiers
for a process which allow cooperating processes to "find each other".
The host-to-host protocols do not care what the process ID is; in
fact the process ID can be blank. Their meaning is only for the
processes which use DIALnet. However, the high-level protocols make
some assumptions for process ID's, and NCP's at each host may want to
make other assumptions as well.
By using process ID's in the connection operation, the NCP's at each
host will know where network traffic that is received is to go, and
when a process gives the NCP something to send over the network, where
it should send the packet (ie, from what socket).
THE NETWORK CONTROL PROGRAM
The network control program is the process within each host which
is responsible for establishing and breaking connections as well as
controlling the data flow over the connections. Normally, the NCP
will be part of the operating system or the front end processor.
For the NCP to perform its work, it must communicate with the NCPs
running on other hosts. To allow this, a rigidly formatted packet
structure has been established for messages exchanged between the
individual NCP's. The format of this packet is discussed on the
next page.
Most of the op-codes are associated with NCP communication and not
with individual links. In fact, normal tertiary messages are sent
using the MSG op-code. Hopefully MSG packets will account for the
overwhelming majority of protocol transmissions.
For NCP to NCP messages, the byte size of all the fields is 8 or
some multiple of 8. However, for messages that are going to be
processed by tertiary processes, it is often desirable for the
connection to use some byte size other than 8 which is mutually
convenient to both hosts. For example, PDP-10's may wish to use
a 36-bit byte size. Because of this, when a link is established
the NCP's must agree on a connection byte size. In general, both
NCP's must be able to accept 8-bit tranmission, but should be
willing to go to some other byte size that is more convenient to
their respective tertiary processes.
Another unique thing about NCP to NCP messages is that such messages
are always transmitted over socket 0.
Of course, packets as transmitted over the network are sent in 8-
bit bytes and it is the responsibility of the NCP to do the necessary
concatenation or byte-loading and bit shifting.
The network packets themselves have the same general format,
illustrated on the next page. They begin with a fixed start of
packet code, followed by an op code, followed by the rest of the
packet contents, and terminated by a checksum and an end of packet
code. The reason for this rather inflexible scheme was to make
implementation as simple as possible and to provide a clear,
unambigious format for packets. Using this scheme it is possible
for the same read-packet routine to read all types of input packets.
PACKET FORMAT
_________________________________________
| PACKET HEADER |
|=======================================|
| |
byte 0 | SOP code |
| |
|---------------------------------------|
| |
byte 1 | Op code |
| |
|---------------------------------------|
| |
byte 2 | Sender socket number |
| |
|---------------------------------------|
| |
byte 3 | Receiver socket number |
| |
|---------------------------------------|
| |
byte 4 | Data Part size |
| |
|---------------------------------------|
| |
byte 5 | Packet number |
| |
|=======================================|
| PACKET DATA (optional) |
|=======================================|
| |
| |
| |
| |
| Data (n bytes) |
| |
| |
| |
| |
|=======================================|
| PACKET TRAILER |
|=======================================|
| |
bytes 0-3 | Packet checksum |
| |
|---------------------------------------|
| |
byte 4 | EOP code |
| |
|_______________________________________|
NOTES ON PACKET FORMAT
The SOP code is constant. Any code received outside of a packet that
is not an SOP code is in violation of protocol.
The op code tells the recepient what the purpose of this packet was
and what functions it should perform.
The sender socket number is the socket number assigned by the sender
for this link. Packets that are sent from the sender's NCP and not
on behalf of a process should have a sender socket number of 0.
The receiver socket number is the socket number assigned by the
receiver for this link. Packets that are sent to the receiver's NCP
and not to one of the receiver's processes should have a receiver
socket number of 0.
The data count is the number of 8-bit bytes of data to follow. Zero
is legal.
The packet checksum is generated by an as-yet undetermined algorithm
and is a checksum of the ENTIRE packet, including the SOP, EOP and the
checksum itself!
The EOP code is a constant and must terminate a packet; any other code
received in this position is a violation of protocol.
OP CODES
NOTE: It should be noted that in the NCP commands described below
that a distinction is made in individual commands between
REQUEST and DEMAND. A REQUEST asks the other host to perform
a service which, at its (the other host) option, it may
agree or refuse to perform. A DEMAND is an order to the
other host to perform a service which it (the other host)
has no right to refuse.
Typically a REQUEST is a request for an optional service,
while a DEMAND is an order not to perform such an optional
service but rather to use the default state.
Of course, since the default state is silence in both
directions, a host should not arbitrarily refuse all requests
if it intends to use DIALnet for anything!
For NCP-NCP only codes (ie, those which do not involve the tertiary
processes), the link number field must be zero.
In the descriptions below, certain arguments are passed along with
the commands. These arguments are listed in the order in which they
occur, along with their bit size (by conspiracy, always a multiple of
8.). They all occur in the DATA field of the packet. NCP to NCP
data can be distinguished from data passed between tertiary processes
by examining the link number, which is 0 for NCP messages. Hence the
meaning of "data" as defined in the packet is unambigious.
Codes 036 and 037 are specifically illegal and are never used.
SEQUENTIAL LIST OF NETWORK CODES
CODE 001 RPC REQUEST PROCESS CONNECTION process → NCP message
32. Process ID of process requesting connection
32. Process ID of process to be connected to
This is the basic establish connection command. It serves a dual
purpose; to request establishment of a connection between receiver and
sender, and to establish the connection between sender and receiver.
See below under "establishing a connection".
CODE 002 DPT DEMAND PROCESS TERMINATION NCP → process message
This is the basic terminate connection command. It may either
terminate an existing connection or abort a request for one.
CODE 003 GFA GIVE FURTHER ALLOCATION NCP → process message
16. Bytes of allocation
This is the data allocation command. The initial allocation is infinite.
If this feature is used, the receiver may send only up to the specified
number of bytes before it must wait for a further allocation. Sending an
allocation of zero implies infinite allocation. This is for hosts which
are not confident of their ability to handle continuous data transmission
without buffer overflow.
CODE 004 MSG MESSAGE process ↔ process message
MSGSIZ Message passed to tertiary process
This is the basic data transmission command. The link number in the
protocol block specifies the intended destination of the message. A
connection must be open on the specified link.
CODE 005 ERR ERROR REPORT NCP ↔ NCP message
8. Error condition code:
0 Illegal
1 Sent RPC on existing link
2 Sent DPT on non-existant link
3 Sent GFA on non-existant link
4 Sent MSG on non-existant link
5 Packet not received properly, re-transmit
8. Packet sequence number of packet you are unhappy with
This is the command to tell the other host you are unhappy with something.
CODE 006 RST RESET NCP ↔ NCP message
Close all connections, abort all processes. This command may be sent
by a Host which has just been restarted following a service interruption.
It instructs the other host to forget all links, etc.
ESTABLISHING AND TERMINATING A CONNECTION
This is the basic mechanism in establishing a connection between two
tertiary processes in a simlex connection. In the discussion below,
U refers to the process which initially provokes the connection or
USER, S refers to the the process passively waiting for a connection
or SERVER.
U must know the process ID of the S it wants to connect to. As far
as DIALnet is concerned, process ID's are arbitrary ASCII strings.
However, conventions have been established as noted elsewhere.
U must also have a process ID of its own, and have a socket number
which identifies the link to U's NCP. The socket number must refer
to an unused socket not connected to any link. The process ID is
arbitrary; however, the higher level protocols in many cases expect
certain process ID's.
U sends a REQUEST PROCESS CONNECTION with its process ID and S's
process ID; for the sender socket number the socket where the
connection is to be made to is used. As the message goes to S's NCP,
the receiver socket number is 0.
The NCP at S's host passes the request along to S. S may have been
listening for a connection, or perhaps was created by the NCP as a
result of the REQUEST PROCESS CONNECTION. If no such process exists
or the NCP is unable to create the process, the NCP should refuse the
connection (discussed below).
S then decides whether or not it wants to talk to U. If not, it
instructs the NCP to refuse the connection. Otherwise, it accepts
the connection by instructing the NCP to send a REQUEST PROCESS
CONNECTION back to U's NCP. This RPC is sent as if S were trying to
initiate a connection with U instead of the other way around; ie,
S's socket is put in the sender socket number and 0 is used for the
receiver socket number! Thus, in a race condition, all the right
things happen automagically.
Once a connection has been established, the process ID is no longer
used by the host-host protocol. What higher-level protocols do with
the process ID is discussed in their description.
If the NCP is to refuse the connection, it sends a DEMAND PROCESS
TERMINATION to U's socket, from S's NCP (ie, the sender socket number
is 0).
If a connection is terminated, the recepient of the DEMAND PROCESS
TERMINATION should send a DEMAND PROCESS TERMINATION to confirm
receiving the demand. This avoids timing errors and confusion that
could occur if both ends want to close the connection at about the
same time and both send almost simultaneous DEMAND PROCESS TERMINATIONs.
The result is that if a host receives a DEMAND PROCESS TERMINATION
before it sends its own, it is obeying the other host by sending its
own and the connection is closed. If it receives the DEMAND PROCESS
TERMINATION after it had sent its own, then it thinks it is getting
a confirmation and the connection is closed; hence, no deadlock can
occur.
GLOSSARY
The following terms are used in this document and are defined here
to remove ambiguity:
CHECKSUM a 32-bit quantity containing a checksum of
the entire packet, including SOP and EOP
markers. The algorithm has not been decided
yet.
DATA an arbitrary amount of data which is either
used as arguments to the NCP or as data to
be passed to the processes utilizing DIALnet.
DATA COUNT a 16-bit quantity indicating how many bytes
are in the data field of the packet. This
quantity may be 0, in which case there is no
data field.
EOP an 8-bit quantity indicating end of packet.
The current value of the EOP code is 036 and
it is a violation of protocol for a packet to
end with anything other than this code. Also,
a packet can not be considered to have been
completely received until this code has been
received. An 036 that occurs at any other
point must be quoted with an 037.
LINK a logical connection between two processes.
Links are bidirectional, and several may
exist on a single phone connection.
NETWORK CONTROL PROGRAM the process on each host responsible for the
host-host communications on that host. All
the other processes on that host send and
receive their traffic through the NCP.
OP CODE a DIALnet host-host protocol operation code.
PACKET a logical unit of data transmitted over a
DIALnet link. The packet is the elementary
unit of DIALnet transmissions. A packet is
basically data with a header and trailer.
PACKET ID an 8-bit quantity which uniquely identifies
a packet at a given point in time. This is
used to identify packets if necessary in
error recovery. Packet ID's may be recycled
after both hosts have agreed that the packet
associated with this packet ID has been
correctly sent and received.
PROCESS an entity utilizing DIALnet. DIALnet traffic
consists of communications between processes.
PROCESS ID an ASCII string (currently 4 8 bit bytes) which
uniquely identifies the process.
SERVER the initially passive process in a link. Note
that a server is not necessarily the receiver
of the phone call, although this is normally
SOCKET one of two ends of a link; a socket is a
theoretical "connection" between the link and
the host. Socket 0 is used by the NCP; other
sockets are used by processes. The concept of
a socket is for convenience only.
SOCKET NUMBER an 8-bit quantity which uniquely identifies
the link to this host on this connection.
Socket numbers are allocated by the owner of
the socket, and may be any value except 0,
which is reserved for the NCP.
SOP an 8-bit quantity indicating end of packet,
included for redundancy. The current value of
the SOP code is 037 and it is a violation of
protocol for a packet to begin with anything
other than this code. Hence, unless a packet
is in the process of being transmitted, no
other code other than 037 should be transmitted
or received. An 037 which occurs at any other
point must be quoted with an 037.
USER the initially active process in a link. Note
that a user is not necessarily the initiator
of the phone call, although this is normally
the case for the initial links.